Welcome to the Qualys Container Security Assessment and Response training. 


In this course, we will discuss how to deploy, configure and manage the Qualys 
Container Security application and use its features to secure the build, ship and run 
phase of the container lifecycle. 


Training Documents 


e Presentation Slide 
e LAB Tutorial Supplement 
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Land 


Swapcard Training Event Page 
(Download link at the bottom) 


OR 


Qualys SharePoint Server 
https://bit.ly/3DxxP2C 


You can download the training documents needed to complete the Container Security 
Assessment and Response course from the link posted to Swapcard or from the 
shortened link shown on this slide. 


Note that you will need a PDF reader like Adobe Acrobat to view these files. 


Lab Tutorial Supplement 


All lab activity for this course is performed in a simulated lab 
environment (No student trial account required) 


Please consult the Container Security Lab Tutorial Supplement for the 
following: 


Link to start the lab tutorial (separate link(s) for each lab topic 
placed next to the “PLAY” sign) 


Overview of the steps performed for each topic 


Additional supporting information 


Participants will perform all lab activity for this training ina simulated lab 
environment. And so, you do not require a student trial account for this training. 


Please consult the Container Security Lab Tutorial Supplement for getting started with 
lab tutorials. 


Starting the Lab Tutorial @ 


Open this link or copy/paste 


the link in a separate 
Navigate to the following URL to view the “Install Container Sensor on a Docker Host” browser window/tab 
tutorial: 


EX _http://ior.ad/7hbj @ 
: Maximize the 
&@ iorad.com/player/1734345/CS--Install-Container-Sensor-on-Docker-Host#trysteps-1 screen 


25 steps / 5 mins 


CS- Install Container 
Sensor on Docker 


me Start the 
tutorial 


Read through the Lab tutorial supplement and you will find a lab tutorial link under 
each topic. Open the link ina separate browser tab or window and start the lab 


tutorial. 
Collapse the lab window when done and read through the lab tutorial supplement for 


additional information. 


Agenda 


Container Security Overview 

Qualys Container Security Use Cases 

Container Sensor Overview and Deployment (LAB) 

Container Sensor Deployment in Orchestration Platforms (LAB) 
Visibility into Container Projects (LAB) 

Assess Containerized Applications (LAB) 

Secure the Build Pipeline (LAB) 

Secure the Registry (LAB) 


Secure Containers in the Runtime Environment (LAB) 


We’ll begin this training class with an overview of the security concerns associated 
with container technology and make practical recommendations for addressing those 
concerns. 


Next, we will discuss the key uses of the Qualys Container Security application to 
mitigate container security related risks. 


From there, we will provide an overview of the container sensor which is used for 
identifying vulnerabilities and misconfigurations in images and containers in the 
different container lifecycle phases. This will also include an overview of the Sensor 
deployment options. 


Extending on the Container Sensor deployment topic, we will talk about deploying 
the Sensor in Container orchestration environments suchas Kubernetes, AWS ECS 
and others. 


Then we will discuss how you can use Qualys Sensors suchas Scanners and Cloud 
Agents to gain visibility into your Container environment and identify hosts where you 
can deploy the Container Security application. We will also discuss, how you can gain 
insight into the image sources and identify unknown Registry locations not covered 
by Container Security. 


In the following topic, you'll build a very simple containerized application and identify 
the vulnerability findings and other useful information that is captured by the Qualys 
Container Sensor. 


Next, we will discuss Container Security integration with CI/CD tools like Jenkins and 
others and understand how to secure images in the build pipeline. 


Then we will talk about securing the Container Registry by deploying the Registry 
Sensor and setting up scan jobs in the Container Security application. 


Finally, we’ll finish the course with a discussion of the configuration and a functional 
overview of Qualys Container Runtime Security feature. 


In this section, we will provide you an overview of Container Security challenges and 
discuss the guidelines for overcoming those challenges. 


Introduction to Container Security 


e Container security is the process of implementing security tools and 
policies to protect the infrastructure, the software supply chain, 
runtime, and everything in between 

e Container security differs from traditional security methods due to the 


increased complexity and dynamism of the container environment. 


Container security is the process of implementing security tools and policies that will 
give you the assurance that everything in your container is running as intended. This 
includes protecting the infrastructure, the software supply chain, runtime, and 
everything in between. 


Container security differs from traditional security methods due to the increased 
complexity and dynamism of the container environment. So using traditional 
approaches and tools to securing the container ecosystem won't be very effective. 


Containers Bring Unique Security Challenges 


Containers use an open development platform (docker pull 
mysql:latest). 
Containers are by design stateless and ephemeral 


Traditional scheduled scanning will not reliably show vulnerabilities and 
security concerns in a containerized environment 


Unlike a traditional server environment, you do not patch containers. 
Patching and vulnerability remediation must be done on the images 


While containers are popular, there are some unique challenges to container security. 


Many of the image resources used in container applications come from public 
registries like Docker Hub. It’s possible that malicious files could be included 
intentionally or inadvertently within these images. 


Containers are by design stateless and ephemeral. And so traditional scheduled 
scanning will not reliably show a containerized environment vulnerabilities and 
security concerns. 


Unlike a traditional server environment, you do not patch containers. Patching and 
vulnerability remediation must be done on the images. 


Container Attack Vectors 


* Container Vulnerabilities 
Container Image Vulnerabilities and Misconfiguration 


and Misconfiguration a Conan hana 


Misconfiguration 


* Container Escape 
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A container environment, in general, encompasses your images, containers, container 
runtime (Docker, runC, cri-o, containerd), registries, orchestration tools and the host 
where images are stored and containers are deployed. 


Understanding risks associated with these components and how to protect your 
environment against such risks is essential. 


Container Host 

The container host is typically a Linux operating system that runs the Docker daemon. 
Without carefully selecting the right container host operating system and then taking 
pains to reduce its attack surface, you could give attackers a foothold into your 
environment. One point of attack might be package vulnerabilities in the operating 
system. Another attack vector materializes due to misconfiguration. For instance, 
when you manage a container through access rights granted to the underlying 
container host, creates unnecessary risk. 


Container Engine and Orchestration Tools 

The container engine running on the host, the orchestration tools such as Kubernetes 
and the management platforms built on top of it can be vulnerable to attacks if not 
protected. These expose potentially new attack surfaces for container deployments 
which previously did not exist, and thus will be attempted to be exploited by hackers. 
Because these components exist low inthe container technology architecture, they 


canimpact all the containers and applications that run on these components. So its 
important to include these insecurity, compliance and audit checks using relevant 
benchmarks and standards. 


Containerized Applications 

Just like traditional apps, containerized apps are vulnerable to software flaws, which 
an attacker can exploit to gain unauthorized access to sensitive data, attack other 
containers, or attack the host operating system. Because containers share the same 
kernel and canbe run with varying capabilities and privileges on a host, the degree of 
segmentation between them is less. 


Container Images 

Vulnerabilities, defects, malware, and plain-text password can mar container 
images— and such risks shift from possible to probable when the provenance of a 
container is dubious or unknown. The portability of containers makes it easy to 
obtain an image and run it to solve an immediate problem but using untrusted 
images in haste can introduce malware into an environment, lead to a data breach, or 
highlight a vulnerability. An image of unknown origin or with unknown base layers 
can contain malicious files. Further, the components in an image might be missing 
security updates or patches, exposing vulnerabilities that an attacker can exploit. 
Meanwhile, defects can take root in configurations, such as being run with more 
privileges than required, or in unnecessary components, such as the SSH daemon. 
There is also the risk of embedded secrets that you don’t know about. An image can 
contain plain-text passwords or private keys that let one component of an app 
connect to another, but anyone with access to the image can find the secret and use 
it to do harm. 


Container Runtime 

A containerized application with unrestricted outbound network access can let an 
attacker who has gained control of a container scan for other weaknesses to exploit. 
And one of those weaknesses can reside in an insecure runtime configuration, 
especially if a container is run in privileged mode or allowed to mount sensitive 
directories on the host. In testing an app, developers can unleash unscanned images 
or misconfigured containers that turn into drift containers, extending an open 
invitation to attackers, especially when such containers persist beyond a short test 
cycle. Finally, there is the possibility of an attacker escaping from one container and 
jumping over to another. It’s important to keep the container runtime itself (typically, 
Docker) patched and up to date to avoid the possibility of a container escape. 


Container Lifecycle Concerns 


Container Instances 


Container | mages Container Registry Infrastructure 


Run 


Host Protection 
Container Engine 
Benchmarking 
Container Orchestration 
Benchmarking 
Container Vulnerabilities 
and Misconfigurations 
Deep Runtime Visibility 
Runtime Protection 


Software Composition Registry Scanning 
Vulnerabilities and Registry Hygiene 


Misconfigurations Vulnerabilities and 
Integration with CI Misconfigurations 
Pipelines Image Source 


Another way to understand the security requirements of the container technology 
architecture, is to consider the container lifecycle phases. 


The three main container lifecycle phases involve building software, shipping itto a 
registry and then deploying it into production or test environment. 
Let’s understand these phases further and the challenges involved at each stage. 


The first phase is the ‘Build’ phase, where images are being built by developers. Here 
you want to look into the software composition of the image and their vulnerabilities 
and misconfigurations. Here integration with CI tools and pipeline is important. 


Once the images are built, they get pushed to the next phase of deployment which is 
the ‘Ship’ phase. Registries are typically trusted as a source of valid, approved 
software, and as such compromise of a registry can potentially lead to compromise of 
downstream containers and hosts. So, registry scanning becomes more important at 
this stage. Here its important to identify the image source and ensure that developers 
are pushing compliant images to the registry. To do this, security teams must have 
information and visibility to ensure that the right guidelines are being followed and 
only compliant images get to the registry. 


The final stage in the container lifecycle is the ‘Run’ phase. There are many things to 
consider at this stage. 
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Here its important to consider the security of the entire ecosystem including the host, 
Container Engine, Orchestration tools and networks in addition to the security of the 
actual running containers. You need to have visibility into your containers hosts and 
inventory. You also need deep visibility inside the container and find what's installed 
on them, where it came from, like the approved build registry, the approved pipeline 
and soon. And then there's the question of protecting the container runtime against 
known and unknown vulnerabilities and malicious behavior of the application running 
inside the container. 
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Addressing Container Security Challenges 


CI/CD integration 
e Block vulnerable images from making it to production 
e Provide self-service so that developers can fix/mitigate issues quickly 


Registry Scanning 
e Gain visibility into images stored in public/private registries 
e Scan images in all registry locations 


Container Runtime Assessment and Enforcement 

e Perform real time, event driven assessments of containers in the 
runtime environment 

e Block malicious runtime behaviour 


Container Host Scanning 
e Perform vulnerability and configuration assessment of the container 
host 


Addressing Container Security challenges requires a different approach. And that is 
achieved by shifting security to the left. In its most simple terms, “shift left” security 
is moving security to the earliest possible point in the development process. Here 
security and compliance tools and processes are integrated into the development 
process. This involves embedding security processes and tools in the CI/CD pipeline, 
resulting in automated security gates. So, when a build fails, development teams 
receive real time feedback on the reason for failure. This provides a better context for 
remediation. Developers can then take immediate action to resolve/patch/mitigate 
any vulnerabilities. 


And then as these images are pushed to the registry, with registry scanning you 
should be able to identify image sources, ensure compliance and maintain registry 
hygiene. 


And with security tools already built-in during the pre-deployment stage, it will be 
easier to monitor containers in their runtime environment and block any unintended 


or malicious behaviour. 


And lastly, you should also assess and address any vulnerability and compliance gaps 
of the underlying container host. 
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In this section, we will provide an overview of the key use cases of the Qualys 
Container Security application. 
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Qualys Container Security 


Key Use Cases 


Visibility into your container projects æ Secure the CI/CD pipeline 


Identify hosts with containers . Integrate images, vulnerability scansinto 
Inventory ofimages, containers the build 

Search images and containers with vulnerabilities, . FAIL builds, not allowing unsecure images 
misconfigurations, labels, tags, packages,.. to enter the pipeline 

Build custom widgets 


Scan Registry and Maintain Registry Container Runtime Visibility and 
Hygiene Protection 


Inventory and scan as new images are added Detect container drift from underlying 


to the registry 
Regularly scan registry for non-compliant 
imagesas per policy 


image 
Policy driven visibility and enforcement of 
container runtime behavior 


Qualys Container Security provides security teams a comprehensive container 
security program across the build-ship-run phase of the container pipeline. 


Deploying Qualys Container Security Sensors onto your docker host assets will 
provide you with image and container inventory that give you greater visibility into 
your container projects. 


With container vulnerability management and configuration assessment, Container 
Security will help you detect vulnerabilities and misconfigurations inimages and their 
associated containers. 


With Qualys plugins for popular CI/CD pipeline tools like Jenkins and Bamboo, you 
can block images containing high risk vulnerabilities from entering your production 
registries. 


With registry scanning, we will ensure that only images from trusted image sources 
that have been appropriately secured during the build phase make it to the registry. 


With deep visibility into the application runtime environment, Container Security 
application will help you identify suspicious or “drift” containers. Drift Containers 
contain vulnerabilities or software, not found inthe image from which the container 
is spawned. This is typically considered to be abnormal behavior and may even be an 
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indication of some type of malicious activity that needs to be investigated. 


Lastly, with Qualys Container Runtime Security, you can perform 

comprehensive, policy-driven monitoring and blocking of malicious container runtime 
behaviour including file access, network communications and process behaviours. 
The Qualys approach empowers security to follow the container image with built-in 
instrumentation, enabling visibility and behaviour enforcement for running 
containers. The solution also facilitates a ‘follow the container’ approach, providing 
DevOps and application teams future-proof development protection as applications 
migrate to more mature container and managed container environments such as 
Docker, Kubernetes, AWS Fargate and others. 
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In this section, we will provide an overview of the Qualys Container Sensor and 
identify the requirements for installing this sensor. 
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Qualys Container Sensor 


Designed for native support of 
Docker environments 


Available asa docker image and 
runs as a non- privileged 


container 9 
c c Cc Ç E C E C € E G E C 


2 3 || 4 5 


Pre-configured to communicate : 
with the Qualys Cloud platform on Host / WM Host / VM Host / VM 


TCP port 443 and supports proxy ica 
SWARM 


servers a 


Deployable on standalone as well 
as in clustered environments such 
as Kubernetes, AWS ECS, Docker 
Swarm, Mesos, etc. 


Qualys has developed a container native sensor to assess the vulnerability posture of 
components such as images, containers and container registry that make up the 
container ecosystem. 


It is packaged and delivered as a Docker Image and must be installed on each Docker 
host containing images and containers for scanning. It runs as a non-privileged 
container alongside other application containers on the Docker host. 


By default, Container Sensor is pre-configured to communicate with the Qualys Cloud 
platform on TCP port 443. Alternately, it can be configured to support proxy servers. 


It can be deployed on hosts in your data centre or cloud environments like AWS, 
Azure, Google and others. It can also be deployed into Container orchestration 
environments like Kubernetes, Mesos or Docker Swarm just like any other application 
container. 
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Container Sensor Functionality 


Automatic Discovery Monitoring & Listing & Vulnerabilityand 
of Images and Reporting of Scanning of Compliance 


Containers Docker Events Registry Images assessment of Images 
and Containers 


Docker host vulnerability and compliance posture require Qualys Cloud Agents 
or an authenticated scan through a Qualys Scanner Appliance. 


The Container Sensor does automatic discovery of images and containers on the host. 
It uses commands suchas docker ps to lists all images and containers in the 
environment. It also gets low level data on these docker objects using commands like 
docker inspect and docker info. 


It also monitors and reports on the docker events related to images and containers 
like ‘created, started, killed, push, pull, etc.’ 


The sensor lists and scans registries for vulnerable images. 


Lastly, it provides a vulnerability and compliance analysis of images and containers. 
This is the output of the vulnerability management and compliance manifests run for 
identifying vulnerability and misconfiguration information in images and containers. 
Compliance assessment is supported for Open Container Image (OCI) compliant 
images and running containers. We support a subset of controls from CIS Docker 
benchmarks, which are applicable to running containers and images. 


Note that the Container Sensor only scans Images and Containers stored or cached on 
a container host or in a registry. For getting the vulnerability and compliance posture 
of the host, you would require Qualys Cloud Agents or an authenticated scan 
through a Qualys Scanner Appliance. Unauthenticated scans will not resolve the 
Qualys QIDs for container and image information or perform evaluations of the 
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compliance of the host or docker engine. 
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Scanning Container Images with Qualys 


Scan vulnerable images and images layers 


Complete image introspection, 
understanding how layers work 
in unison resulting in higher 

accuracy vulnerability detection 


Detailed re port of vulnerable 
software with patchable 


version information 

IMAGE INSTALLED FIXVER 
VULNERABILITIES S/W LAYER ID COMPONENT a 
QID870045 — glib 1.3 Glibc 1.4 La ye r details induded to 
SEVERITY 5 SPAASS TERON, Se identify the composition of the 
QID870045 — libxm12.0 Libxm12.2 image 
SEVERITY 4 c72657477h CMD APACHE2.1 

/ust/.. RPM 


The Qualys Container Security application uses complete image introspection to 
assessing the various layers within a docker image. 


When scanning in the Cl or build phase, any individual image layer that does not meet 
your defined PASS/FAIL conditions will prevent the parent image from reaching the 
repository. 


In this illustration, the top two image layers require patching before the parent image 
can PASS or move to the next phase in the Cl pipeline. 


Complete image introspection and understanding how layers work in unison results in 
higher accuracy vulnerability detection. 


System and Application Support 


Qualys Container Security Sensors upports 
systems running Docker version 1.12 and 
greater, on: 

= Ubuntu 


< Download and Deploy Qualys Container Sensor 


a Debian Download and Deploy Qualys Container Sensor 


= Red Hat Enterprise 
= Fedora A- © Bull (c/co) 
= CentOS 
= MacOS 
= CoreOS 


Can be deployedas: 
= General (Host) Sensor 
= Registry Sensor 
= Build (CI/CD) Sensor 


The Container Sensor supports Linux, CoreOS and MacOS based container hosts 
running Docker version 1.12 and greater. It can be deployed on standalone or 
clustered hosts. 

Please note that Container Sensor deployment on a host running Mac or CoreOS, 
requires special installation steps. 


It can be deployed in various modes to support continuous scanning of images and 
containers in the build, ship and run phase of the container lifecycle. 


When the sensor is deployed in the build or Cl/CD mode, it supports scanning of 
images in the CI/CD pipeline. 

When deployed in the Registry mode, it scans images ina public or private registry. 
And inthe General mode, it can scanimages and containers on any host, except for 
images in the Registry or in the CI/CD pipeline. 


Please consult the Qualys Container Security Sensor Deployment Guide for more 
information 
https ://www.qualys.com/docs/qualys-container-sensor-deployment-guide.pdf 
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Deploying Qualys Container Security 


Qualys Cl 


i Regist! 
Heak QJ Azure DevOps Ra 


Image 


e Bamboo 4) Repository 
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(£) Jenkins Citcleci p 
) Lie Qualys General Runtime 
egistry Sensor Securit 


Qualys CI/CD Sensor 


Build Host Registry Scanning 
Qualys Cloud 


Host 
EE >» ED agent 


Pre-Deployment Phase Post-Deployment Phase 


© Represents an installed Qualys Sensor/P lugin 


Here’s an overview of integrating Qualys Container security with the different phases 
of the container lifecycle. 


In the “build” phase, you can deploy the Qualys plugin or use scripts along with the 
CI/CD Sensor. 

The Qualys plugin or a script allows the Qualys scan stage to be added to the build 
pipeline so that images can be scanned automatically as a part of the build process. 
And this allows you to configure a policy to pass or fail an image based on its 
vulnerability posture. The plugin or script works with the CI/CD Sensor to secure 
images inthe build pipeline. 


In the “Ship” phase, you need to scan the image registry. This is achieved by 
deploying the Registry Sensor on a Docker host that has access to the registry. Your 
registries or network topology may require multiple registry sensors to be deployed 
in your environment. Also, any registry that must be scanned must be added to the 
Container Security application. 


After images are built and shipped to a registry, they are pulled and deployed ina 
production or test environment. Here, the General Sensor is used to scans images 
and containers on a container host except for images in the registry or inthe CICD 
pipeline. In this phase, you can also implement Container Runtime Security (CRS) for 
deep runtime visibility and protection. This involves embedding a lightweight snippet 
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of the Qualys code into the container image. This embedded layer facilitates policy- 
driven monitoring, detection and blocking of malicious container behavior at runtime. 


Last but not the least, it’s also important to identify and mitigate vulnerability and 
compliance gaps on the host where images are stored, and containers are deployed. 
This host level assessment is done by Qualys Vulnerability Management (VM) and 
Policy Compliance (PC) applications by using sensors such as Scanner appliances and 
Cloud Agents. These sensors also discover container hosts and provide information 
about the image and container inventory. This visibility assists security teams to 
identify hosts missing Container Security and helps them eliminate blind spots in their 
environment. 
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Full Stack Solution for RedHat OpenShift 


Container Sensor 
(Vulnerability and 
Compliance Assessment of 
containers and images) 


Cloud Agent for RedHat (@) © 
Core OS on OpenShift 4.x 
(Host level assessment) 


In-Container 
Instrumentation 


@ əuzu 
@ 1əu1e}uo9 


(Runtime visibility and 


OpenShift 4.x Protection) 


OpenShift 4.x Infrastructure CRI-O 
Security RCOS 


© Represents an installed Qualys Sensor 


At Qualys, we have focused on delivering a full stack solution for Red Hat OpenShift. 
To do this, we utilize both Container Sensors and Cloud Agents. 


As you can see in the diagram, our container sensor solution is deployed as its own 
container. It assesses images and running containers in your runtime environment. 
This solution is technically independent from the Cloud Agent container and provides 
inventory, vulnerability, and compliance assessments; with data merging and sharing 
between modules on the Qualys Cloud Platform. 


Our Container Security Solution has been inthe market for a while now and supports 
Docker, Container-D, and Crio runtimes. 


RedHat CoreOS (RCOS) does not permit modification of the host. Our unique 
solution, uses an agent-as-a-container approach for host level vulnerability and 
compliance assessment. 
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Easily deployed, our containerized agent scans the Host OS to provide visibility, 
actionable intelligence, and auditing. 


Qualys full-stack security for Red Hat OpenShift adds visibility, actionable intelligence, 
and security auditing for RCOS, the operating system that underpins OpenShift 
deployments for running containers securely. With this solution you can manage and 
reduce risk at both the host OS and container levels. Built on the Qualys Cloud 
Platform, Qualys’ solution seamlessly integrates with customers’ vulnerability 
management workflows, reporting and metrics to help reduce risk. 
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LAB 1 


Install Container Sensor on a Docker Host 


Please consult pages 3-9 in the Lab Tutorial 
Supplement for instructions to perform this 


lab activity. 


10 mins 
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In this section, we will discuss the requirements and the process for deploying the 
Qualys Container Sensor in Container Orchestration Environments such as 
Kubernetes, Docker Swarm and others. 


22 


Qualys Container Security in a Container Orchestration 
Environment 


e Container Orchestration is the automatic - TOSO Contaneriorchestatlon 
process of managing or scheduling of ETN S 
individual containers used for microservices- E (Shas) i 
based applications within multiple clusters Ar - moo Se SAT os 


FROM AMAZON ntainer Services 
"PROM MICROSOFT 


Qualys Container Sens oris Docker based 

and can be deployed into a supported © © 
orchestration tool just like any other 
application container 

Sample deployment templates available © ©) 
Sensor deployment in various Container © 


‘Fron CORES OpenShitt 


Orchestration environments psosphere Marathon FromRed Hat 


From e ovo PLATFORM ee potest’ TOOLS 


Container orchestration is the automatic process of managing or scheduling the work 
of individual containers for applications based on microservices within multiple 
clusters. The orchestration tool also schedules deployment of containers into clusters 
and determines the best host for the container. 


The widely deployed container orchestration platforms are based on open-source 
versions like Kubernetes, Docker Swarm or the commercial version from Red Hat 
OpenShift. 


As the Qualys Container Sensor is Docker based, it can be deployed in Container 
Orchestration platforms just as any other application container. 


Manifests or configurations files tell the container orchestration tool where to deploy 
the container, how to network between containers, where to store logs and so on. 
Qualys provides sample deployment templates for Kubernetes, Docker Swarm, AWS 
ECS and others to define environment specific configuration. 


23 


Container Sensor Deployment Templates 


Template Orchestration Platform Container Runtime 


cssensor-aws-ecs.json AWS ECS Docker 
cssensor-ds.yml Kubernetes Docker 
cssensor-ds_pv_pvc.yml Kubernetes Docker 
cssensor-containerd-ds.yml Kubernetes Containerd 
cssensor-crio-ds.yml Kubernetes CRI-O 
css ensor-swarm-ds.yml DockerSwarm Docker 
cssensor-openshift-ds.yml RedHat Openshift Docker 


css ensor-dcos.json Mes osphere DC/OS Docker 


Qualys provides sample templates for the Container Sensor deployment in various 
Container Orchestration Platforms and runtime environments. Here we have listed 
the template you need for the specific orchestration platform and the container 
runtime. In order to deploy the Sensor using the specific template, you need to 
configure these templates with the required information that is specific to your 
Qualys account and your cluster environment. 
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Download the Deployment Template 


Container Sensor deployment templates can be Sensor deployment templates are also 
downloaded from the Container Security application availablein GitHub 


< Download and Deploy Qualys Container Sensor G Qualys /cs_sensor 


Download and Deploy Qualys Container Sensor 


© 


OF General (Host) Registry © Build (c/co) 


s S 


Docker Swarm Kubernetes Openshift 


Installation Instructions 


© Kubernetes 


DOCKER CONTAINERD CRI-O 


Installation Steps 


E coy 


You can download deployment templates for various Container Orchestration 
Platforms from the Container Security application. Simply select the Sensor type 
(General, Registry or Build) and the cluster environment (Docker Swarm, Kubernetes, 
etc.) to download the deployment template. These templates are also included in the 
Sensor image tar file QualysContainerSensor.tar.xz file. 


In addition, the deployment templates can also be downloaded from a public GitHub 
repository maintained by Qualys https://github.com/Qualys/cs_ sensor 
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Qualys Container Sensor in Kubernetes Cluster 
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This slide illustrates a Kubernetes cluster environment with the Qualys container 
sensor. 


In Kubernetes, application containers are deployed using pods. A pod is a group of 
one or more application containers (such as Docker) and includes shared storage 
(volumes), IP address and information about how to run them. Pods are hosted on 
worker nodes inthe cluster. Docker is the most common container runtime used ina 
Kubernetes pod, but pods support other container runtimes such as Containerd and 
CRIO as well. 


The Qualys container sensor is deployed as a pod, just as any other application 
container, on all worker nodes for visibility and vulnerability assessment of 
application containers running on these nodes. 
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Qualys Container Sensor in Docker Swarm 


Qualys Cloud Platform 


Qualys Container 


Application 
Sensor 


Containers 
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Swarm Worker Nodes 


This slide illustrates a Docker Swarm cluster environment with the Qualys container 
sensor. 


The cluster comprises one or more manager nodes that manage the worker nodes 
and container instances in the cluster. 


In Swarm, objects are typically described in manifests called stack files. These are 
YAML files and describe all the components and configurations of a Swarm app and 
can be used to easily create and delete an application in any Swarm environment. A 
Swarm service is a scalable group of containers with added networking features that 
are maintained automatically by Swarm. 


The Qualys Container Sensor is also deployed using a stack file, just as any other 
application container, on the manager and all worker nodes for visibility and 
vulnerability assessment of application containers running on these nodes. The 
template cssensor-swarm-ds.yml needs to configured with the necessary information 
(Activation ID, Customer ID, Sensor Mode, Proxy settings, etc.) to create a Swarm 
Service for the Sensor. 


27 


Qualys Container Sensor in AWS ECS Environment 


An ECS Service is created using the sensor 
task definition which runs and maintains 
Container Sensor tasks in the cluster 
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Sensor deployment 
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This slide illustrates an AWS ECS environment with the Qualys container sensor. 


ECS is a highly scalable, fast, container management service that makes it easy to run, 
stop, and manage Docker containers on a cluster. ECS has two different models for 
running your containers, which are called launch types. The first is to run ECS tasks on 
EC2 instances that you own, manage, and pay for, but you don’t have to pay per 

task. The second is to use Fargate, a serverless environment for containers fully 
managed by AWS that enables customers to run containers without having to manage 
any underlying infrastructure. With Fargate, customers only get charged for tasks they 
run. 


Please note that Qualys currently supports AWS ECS using only the EC2 launch type 
for Container Sensor deployment. For AWS Fargate launch type, none of the 
Container Sensors can be deployed as the underlying EC2 infrastructure is not 
managed by the customer. The Qualys Container Runtime Security feature can be 
used to secure containers deployed in such an infrastructure. 


The basic unit of a deployment in ECS is a task which is a logical construct that 
models one or more containers. Task definitions specify the container information for 
your application, such as how many containers are part of your task, what resources 
they will use, how they are linked together, and which host ports they will use and so 
on. 
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The Qualys Container Sensor is deployed using a task definition, just as any other 
application container, in the ECS cluster An Amazon ECS service is created using the 


container sensor task definition which runs and maintains specified instances of a 
task definition in the ECS cluster. 
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LAB 2 


Install Container Sensor in a Cluster 


Please consult pages 10-14 in the Lab 
Tutorial Supplement for instructions to 
perform this lab activity. 


10 mins 
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In this section, we will focus into the first use case for Qualys Container Security 
which is about discovery, inventory, and near-real time tracking of container 
environments. 
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Identifying Hosts with Container Images and Containers 


@ Qualys 


Container Security 


„| QIDs used to identify Docker hosts 
and their inventory: 
. | 45367, 45434, 370440 & 48030 
Download and Install Contain 


Qualys Container for hosts/cluster nodes to inventory images, 
containers and detect vulnerabilities 


CY Docker Hosts Discovered 
3 


1.60K 
VW pie 
Download Container Sensor . 


Get Insights What's Next? 
See 


DB View Dashboard © Analyze Vulnerabilities for images 


On the Container Security application Home screen, we summarize the docker host, 
images, and containers that we have found via inventory and vulnerability 
assessments from the Qualys scanners via authenticated scans and Cloud agent 
scans. This provides an overview of the environment based on the last scan interval 
or inventory update. 


Qualys identifies docker hosts and presence of the Qualys Container Sensor by the 
enumeration of 4 QIDs (45367, 45434, 370440, & 48030) that look for the presence 
of docker running, then collects inventory of the docker environment. This 
information is accurate as of the last scan assessment and is not real-time data. 


You can see inventory information about hosts with container images and containers 
on the Home tab and under Assets-> Hosts tab, in the Container Security application. 
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Identify Hosts Missing Sensor 


© Qualys 


Container Security 


Assets 


1 06 a v INVENTORY 


sauces | 106 TEEN 
System Information 


Network Information r 
PROVIDER Download Sensor 

docker 
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Traffic Summary 


Azure VM Information There is no sensor activity recorded 


SECURITY 


Vulnerabilities 


VMDR Prioritization Identify container hosts 
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Container Security 


Under Assets-> Hosts tab, you will find container hosts with and without the 
Container Sensor. 


For hosts missing Container Sensor, they are added to this list when assessed by an 
agent or via an authenticated scan using a scanner appliance. This tabis updated to 
the last assessment of the host resources. 


You can filter hosts that do not have the Container Sensor installed by clicking on 
“Hosts missing Sensor” which automatically populates the following search query: 
not docker.hasSensor:true 


This inventory provides the security team the necessary visibility and coverage 
information for Container Security in their environment. They can then engage with 
the asset owners to begin assessing any unprotected instances for vulnerability and 
configuration assessment and get a handle on their environment. 
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Container Host Inventory 
@ Qualys 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets 


© Asset Details: areas 
Q Search for hosts... 


i 42 kilar Container Summary 
y 
Total Hosts 107 


CONTAINER STATUS 
Hosts missing Sensor 'ONTAINER STATU 


PROVIDER O eames 
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Get container and 
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z > a vulnerability posture 


And if you have container hosts in the cloud, our AssetView or CloudView connectors 
fetch whole lot of metadata about this inventory which is available under the “Hosts” 
tab under the “Assets” section. So, all container inventory information is available in 

one place here. 


Navigating to Asset Details, Container Security section, you can see if the container 
host has the Qualys Container Security sensor deployed on it. 

If the sensor is deployed, you will see container inventory and corresponding 
vulnerability information in one place here. 


Tracking Images Sources 


Identify Images in unprotected Registries 


@ Qualys 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets 
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Total Images 


Quickly identify Images 
in unprotected 


REGISTRY 


Registries 


VULNERABILITIES 


As we scanat the build phase, we have the metadata on our end to identify that the 
image was scanned at this phase. So, if such an image is not found in any of the 
scanned Registries, itis possible that there may be a Registry set up somewhere that 
the security team is unaware of. So, identifying images insuch unprotected Registry 
locations becomes important. 


Queries can be used to quickly identify such information. 

The below query lists images that were scanned inthe build phase but are not 
present in any of the scanned Registry locations or scanned by the General sensor: 
source:CICD and not (source:REGISTRY and source:GENERAL ) 


You can use queries to create dashboard widgets to display and refresh this 
information automatically. 
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Tracking Images Sources 


Identify Unknown Pipelines 


@ Qualys 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets 
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Total Images 


Quickly identify Images 
in unknown Cl/CD 
pipeline 


REGISTRY 


kés.g 


VULNERABILITIES, 


We can verify which images were scanned in the secure build pipeline and which 
ones were not. Images that were not scanned inthe build phase but are present in 
the Registry or deployed in the production environment, can become a concern. It 
could mean that someone introduced a rogue image from outside of the pipeline into 
the production environment. So, identifying such images gives you the visibility you 
need to ensure that people are following the right guidelines that are laid out and 
only compliant images get pushed to the registry and into the production 
environment. 


The below query can be useful to quickly identify images that were not scanned in 
the CI/CD pipeline but are present in a scanned Registry or identified by the General 
sensor: 

not source:CICD and (source:REGISTRY and source:GENERAL ) 
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Identify Container Location in the Cluster 


© Qualys. 


Container Security RIA HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


17 


Total Containers 


VULNERABILITIES 
od Quickly identify containers 
running on the K8 master, 
oa fee = { cluster node, namespace, etc. 


You can use the search tokens illustrated in the slide to search for containers in your 
Kubernetes cluster. These query tokens allow you to search containers running on the 
master node, or a specific cluster node or a cluster pod namespace or find containers 
by the Kubernetes cluster pod controller name or controller type (CronJob, 
DaemonSet, Deployment, Job, Node, ReplicaSet, ReplicationController, 
StatefulSet),etc. 


You can find the list of all container specific search tokens in our Online Help: 


https ://qualysguard.qg2.apps.qualys.com/cs/help/search_tips/search_ui_containers. 
htm 
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LAB 3 


Visibility into Container Projects 


Please consult pages 15-18 in the Lab 
Tutorial Supplement for instructions to 
perform this lab activity. 


10 mins 
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In this section, we will talk about the deployment of a simple containerized 
application on a docker host running the Qualys container sensor. Further, we will 
also discuss how you can use the Qualys Container Security application to view and 
manage the findings captured by the Container Sensor. 
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Containerized Application 


Example 


Run Tomcat when 


CMD [‘catalina.sh”, “run”] 


Dockerfile 


FROM tomcat:latest 

COPY bodgeit.war /usr/local/tomcat/weba pps 
EXPOSE 8080 

CMD [“catalina. sh”, “run” 


jr Le f KPACHE FROM tomcat:latest 


This slide illustrates the different layers that make up a simple container application. 


Image Layers 

The "base layer" of the application will come from Apache Tomcat, which will also 
provide Java and Apache Web Server. The next layer provides the bodgeit war file, 
which must be placed in the tomcat webapps directory. You'll need to expose port 
8080 to allow other applications and users to access the bodgeit store services. You'll 
also want to ensure that Tomcat is running every time this container application is 
started. 


These various layers of this simple container app are specified in a Dockerfile: 


# Use an official Tomcat runtime as a parent image 
FROM tomcat:latest 


# Copy bodgeit.war to webapps 
COPY . /usr/local/tomcat/webapps 


# Make port 8080 available to the world outside this container 
EXPOSE 8080 


# Run tomcat when the container launches 
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CMD ["catalina.sh", "run"] 


When this application is deployed on a container host where the General Sensor is 
deployed, the sensor will automatically discover the image and container, if any and 
scan it for vulnerabilities and misconfigurations. 
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Vulnerability Scanning 


Vulnerability detections use the same trusted Qualys 
Knowledgebase to provide a high accuracy / low noise set of 
vulnerability assessment findings. 


Provides detailed information on how to remediate vulnerabilities. 


Images scanned using a dynamic analysis method to reduce false 
positives. 


Containers and images are scanned to check the presence of any vulnerabilities by 
the Qualys container sensor. 


The Container Security vulnerability detections use the same trusted Qualys 
Knowledgebase and provides detailed information on how you can remediate 
vulnerabilities, showing not just what version is vulnerable but what version you need 
to patch to. We use a subset of the vulnerability signatures ina manifest specifically 
for containers to provide a high accuracy / low noise set of vulnerability assessment 
findings. 


Qualys scans the docker images for vulnerabilities not through static analysis but via a 
non-static method, where it looks at the Image as a complete entity. This process is 
more effective and has lesser false positives (FP) than the more commonly used Static 
Analysis. 


This is primarily software package listing, services running, ports, etc. For example, 
package manager outputs like rom -qa, npm. This is supported across various Linux 
distributions (CentOS, Ubuntu, CoreOS, etc) and across images like Python, NodeJS, 
Ruby, and so on. 


The sensor will perform static scanning for docker images as a fallback mechanism to 
current dynamic scanning incase docker images does not have a shell. Static scanning 
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will not be performed on Docker container or Docker images having a shell. Static 
scanning collects the list of installed software from the Docker image file system to 
find vulnerabilities in the Docker images. The installed software list is retrieved from 
the Package manager metadata files. Package managers supported are RPM, DPKG 
and Alpine. 
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Compliance Scanning 


Supports compliance scanning of OCI compliant images and running 
containers 


Requires General Sensor and CI/CD Sensor version 1.7.0 (or later) 
and Registry Sensor version 1.9.0 (or later) to perform compliance 
scanning of containers and images. 


Uses a subset of CIS Docker benchmark controls for compliance 
assessment. 


Provides compliance posture (PASS or FAIL) and control information. 


Please reach out to your Qualys Technical Account Manager or Qualys Support to have this 
feature enabled for your subscription. 


Qualys supports compliance scanning of OCI (Open Container Image) compliant 
images and running containers. We support a subset of controls from CIS Docker 
benchmarks, which are applicable to running containers and container images. 
Customers can assess configuration risks in their containers and images and 
remediate them based on the Qualys findings. 


Prerequisites 

e The container compliance feature must be enabled for your Qualys subscription. 
Please reach out to your Technical Account Manager or Qualys Support to have 
this feature enabled for your subscription. 

e Upgrade the General Sensor and CI/CD Sensor to version 1.7.0 (or later) and the 
Registry Sensor to version 1.9.0 (or later) to support compliance scanning of 
containers and images. 


The updated Qualys Container Sensor runs an additional scan of configurations in 
containers, images and uploads additional scan metadata to the Qualys backend. 
Based on the scan metadata, the backend performs an assessment against a subset 
of CIS Docker benchmark controls. Such a scan is transparent to customers and 
functions in a similar real-time, cloud native manner like the vulnerability scanning 
feature. 


You'll see compliance information for your images and containers in the Qualys CS 
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user interface, when this feature is enabled. You can also use CS APIs to export 
compliance data for your images and containers. 
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Search Vulnerable Images and Containers 


© Qualys 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGUR| 


Assets OEO images MOCOCA 
Quickly s earch vulnerable 
eo images and containers 


vulnerabilities. authType 
. Syntax Help 


vulnerabilities.category vulnerabilities authType 


Total Images vulnerabilities. customerSeverity Use a text value ##### to find} 
ORACLE_AUTH, etc). See Auth] 


Assets 


= Quickly s earch non-compliant 
registry.redhat io 1.95K images and containers 


Total Images 


REGISTRY 


You can easily search vulnerable and non-compliant images and containers using 
multiple search tokens. 


You can search for vulnerable images and containers by the vulnerability severity, 
category, CVE ID, CVSS score,etc. 


You can search non-compliant images and containers by control ID, control criticality 
(MINIMAL, MEDIUM, SERIOUS, CRITICAL, URGENT) and control posture (PASS, FAIL). 


You can find the list of all support tokens for searching images in our Online Help: 
https://qualysguard.qg2.apps.qualys.com/cs/help/search_tips/search_ui_images.htm 


Vulnerability and Compliance information can also be fetched using APIs. See the 
Qualys Container Security API Guide for more information. 
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Analyze Results 


Identify vulnerable and misconfigured images 


VULNERABILITIES 


The Qualys Container Sensor captures application events and information and sends 
them to the Qualys Cloud Platform, where you can analyze and act upon the results 
and findings. 


All images and containers scanned by the different sensors are listed under the Assets 
section inthe Container Security application. The Images tab shows all images and 
the Containers tab shows all running or stopped containers discovered by the Sensors 
from your environment. 


The “VULNERABILITIES” column shows any vulnerabilities detected on the 
image/container. 


The “COMPLIANCE” column shows Pass/Fail status of the compliance controls 
evaluated, if any, for the instance. 
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Analyze Results 


Identify the impact of a vulnerable image 


© Image Details: qualyssa/demo 


Identify the 
compliance posture of 
the image. 


Identify the risk/threat — 


vulnerability summary and details. Identify the impact — summary of containers 


created from the vulnerable image. 


Here you can also drill down into the details for any image or container to see 
compliance information, including the list of controls that were scanned with control 
details (CID, criticality, statement, category, technologies). 


In the container security space, itis critical to understand the relationship between 
images and their associated containers. Vulnerable images are not exploitable 
vulnerabilities until they are instantiated as a running container. A single vulnerable 
image could be associated with 100s or 1000s of running containers in your 
environment and exponentially increase your expose and risks associated with those 
vulnerabilities. But because of the ephemeral nature of images and containers, you 
should never patcha container. With Containers you assess the images and 
containers, but you patch the image, which will generate a new image ID. Then to 
remediate the vulnerability your teams will redeploy the new image as new 
containers. The old containers will be deleted. As the old image’s associated running 
containers drops to zero, you can close out the vulnerabilities on the old image. 
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Drift Containers 


Containers breaking off from the “immutable” behavior 


© Qualys 


Container Security 


Contain vulnerabilities or 
software, not found in the 
image from which the Assets 
container is spawned. 


Are considered abnormal V7 


Total Containers 


behaviour and may an indicate 
malicious activity 


VULNERABILITIES 
jeverity 5 


HOME DASHBOARD 


Find containers 
having drift software 
or vulnerabilities 


ASSETS 


Vulnerabilities associated with drift containers are classified as either New, 


Fixed or Varied 


Software associated with drift containers is classified as either New or 


Removed 


Another potential security risk that requires further investigation is the presence of 
“drift” containers. Drift is the container breaking away from the immutability of the 
image & container relationship and represents a change in the software and/or 
vulnerability profile of this container. 


Qualys provides this information by comparing each container scan to the previous 


scan and to the corresponding image scans. This provides good information on drift in 


both software configuration and associated vulnerabilities. 


This would be something to alert your DevOps team about to either update the 
image, or possibly investigate further. 


Vulnerabilities associated with drift containers are classified as either New, Fixed or 
Varied: 
New - vulnerabilities found in a container that are not present in the image from 


which the container is spawned. 


Fixed - vulnerabilities not found in the container but are present in the parent 


image. 


Varied - vulnerabilities found in both containers and images, but detection varies 


and is inconsistent between them. 


Software associated with drift containers are classified as new or removed: 
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e New- software found in the Container but not in the image from which the 
container is spawned. 
e Removed -software not seen in the Container but is present in the parent Image. 


The Container Security application provides multiple search tokens to find containers 
having drift software or vulnerabilities. You can find more information on these 
search tokens in our Online Help: 
https://qualysguard.qg2.apps.qualys.com/cs/help/search_tips/search_ui_containers. 
htm 
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Container Inventory 


Overview Dashboard 


Inventory & security posture 
widgets: 

Count of Images, Containers “_ 
Containers by State 2.27K 
Vulnerable Images 


Drift Containers sacs meal a 


Personalize and add custom — : l EI Ë 
widgets 


Tracking the attack surface is important. Dashboards can have widgets to identify 
images with top severity vulnerabilities and which have running containers associated 
with them. Data for the dashboards is populated from Container Security Sensors, 
Qualys Cloud Agents, Scanner performing authenticated scans and protected (with 
CRS Instrumentation) Containers. 


Running scans and then generating vulnerability reports for sharing with developers 
may not be an effective remediation strategy in the fast-paced DevOps world as by 
the time developers investigate the reports, the situation may have changed. So, 
dashboards which track and update vulnerability information, automatically 
presenting a more updated picture, can come in handy. Qualys APIs can also be used 
to extract image and container vulnerability and compliance data for integration with 
third party applications. 


Monitoring vulnerability trends is important. We may see an increasing trend which 
could indicate that the vulnerability management program for containers is broken, or 
it could also mean that a whole new lot of vulnerabilities came out. So, this needs to 
be monitored well. You can create custom dashboards with widgets to track all such 
information. 


With dashboards within the Container Security application, allow you to quickly 
customize widgets that display: 
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Total container and image count 
Containers by state 

Vulnerable images 

Drift containers and more.. 


46 


Custom Dashboard Example 


Scenario 

° Driftcontainers 

e Drift+ Root Privilege containers 

° Drift+ Root Privilege + Severity 5 
Vulnerability containers 


Solution 

Custom widgets to track containers 
matching above criteria 

Query for Widget a 
vulnerabilities.severity:5 and 
isDrift:true and 

isRoot:true 


Like in other Qualys applications, the Container Security Dashboards are fully 
customizable. You can use the QQL to create custom widgets to highlight information 
related to inventory, vulnerabilities, and things like container drift. 


Qualys provides assessment of both the images and containers, so if something 
changes on the container in the software or vulnerability profile from its base image, 
we will highlight that. 


Besides tracking vulnerabilities, its also important to check privileges. Ideally you 
shouldn't be running containers with root privileges. If you don't specify a user in the 
Docker world, the container inherits permissions of the root user which is what the 
docker process is typically based on. Root privilege on the container means that it 
could access additional commands on the host side. So, you really want to bind the 
container to a non-root user while deploying containers. And we also perform this 
check. 


It will be a serious situation when containers are drifting, and they are running in 
privileged mode, and they have severity 5 type of vulnerabilities. This means the 
attack surface is very high. If the environment is locked down which means no drift 
should be happening, but if we see above situation, it could mean a bad actor has got 
in and he is installing malicious software and making other modifications that can 
cause a lot of damage. Its its good to have widgets to track such combinations of 


factors. 


This is an example to illustrate the use of custom widgets to track containers 
matching multiple criteria. 

This highlights a critical scenario where there is a high count of drift containers in the 
environment, some of which are running as root containers and have high severity 
level 5 vulnerabilities on them. 
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LAB 4 


Assess Containerized Applications 


Please consult pages 19-27 in the Lab 
Tutorial Supplement for instructions to 
perform this lab activity. 


15 mins 
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In this section, we will provide an overview of securing the build pipeline using the 
Qualys Container Security application. 
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Qualys Container Security Integration with CI/CD Tools 


Qualys Plugins REST APIs for other CI/CD tools 


@ Jenkins @ Bamboo & ro) Yy 


QJ Azure DevOps circleci zitLab 


Qualys Container Scanning Groovy scripts for image validation and 
Connector and Container Sensor Container Sensor for scanning build 
for scanning build images images 


Easy to deploy and configure Scripts referred/used in CI/CD pipeline 


Connector availablein Jenkins, job 


Bamboo and Azure DevOps 


Scripts available on GitHub 
marketplace 


Securing the build pipeline is about providing necessary security tooling to the 
DevOps teams so that security can be embedded into the build pipeline from the very 
beginning. These tools should be easy to use and support self-service. Qualys 
provides easy to deploy plugins, scripts and API integration to address these 
requirements. 


Qualys provides a vulnerability analysis plugin or the Container Scanning Connector 
for Jenkins, Bamboo and AzureDevOps which is available for deployment from the 
respective marketplace of these CI/CD tools. 


For other CI/CD tools or homegrown tools, Qualys provides scripts which are 
available ina public github repository 
https ://github.com/Qualys/community/tree/master/containerSecurity#validate- 


docker-image-without-plugin 


The Qualys Container Sensor together with the plugin or the script ensure that and 
image and image layers that fail to meet the vulnerability specifications are blocked 
from entering your image repositories, until they are patched. 


And all of this is managed from within the CI/CD tool the developer is already familiar 
with. 
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Deployment Steps 


7 Install and 


Identify Cl tools Deploy CI/CD Install Qualys 
being used. Sensor on each Plugin or configure 
build node (worker script 
node / agent that 


builds the images). Configure image 


validation policy. 


So, let's understand how we integrate with CI/CD tools. 
First step is to identify the CI/CD tools that are in use and the teams that use them. 
This could be Jenkins, Bamboo, Gitlab, AZureDevOps and others. For most part, our 
Vulnerability Management scan can identify such tools. 


Once this is identified, we need to consider deploying the solution, which in this case 
is the Qualys Build or CI/CD Sensor on the node that's building the container image. 


One of the most common CICD tool being used today is Jenkins. It has a distributed 
architecture that comprises of a master node and one or more worker\build nodes. 
The Build (CI/CD) Sensor needs to be deployed in CI/CD mode on each node where 
the build happens. The Build node must have a docker engine and the CI/CD sensor 
needs access to the docker runtime. 


In other scenarios ephemeral build nodes may be used, meaning a build node spins 
up dynamically, builds an image and then spins down. Docker in Docker (DIND) is an 
example of such an environment where ephemeral build nodes are used. DINDis a 
Docker project that allows Docker engine to run as a container inside Docker. DIND 
provides the ability to create multiple Docker hosts with less overhead and is used for 
development and testing. Qualys supports DIND ephemeral build nodes by spinning 
up a Container Sensor per build job. 
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The next step is to install the Qualys plugin for Jenkins or Bamboo or AzureDevOps or 
configure scripts for CI/CD tools. The plugin or script allows the Qualys scan task to be 
added as a part of the build stage and communicates with the Qualys cloud platform 
using REST APIs and pulls vulnerability scan results for the build job. 


You also need to setup policies within the plugin or script that will determine the 
image pass or fail criteria. 
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Integrating Container Security into a CI/CD Environment 
(using plugin) 


. Deploy the CICD Sensor on the build node 

. Deploy the Qualys plugin (vulnerability analysis plugin) on the 
management\master node 

. Configure API access and image validation criteria in the plugin 


. Add the Qualys scan step to the build pipeline 


This slide outlines the steps involved in setting up Qualys Container Security for 
securing the build pipeline in a supported CI/CD environment using the Qualys plugin 
(Container Scanning Connector) and the CI/CD Sensor. 


First, we need to download and deploy the Container Sensor on each node where 
images are built. The Sensor is responsible for performing a vulnerability scan of any 
container image that is built on the node as defined in the build pipeline. 


Next, we need to deploy the Qualys plugin\Container Scanning Connector on the 
management or master node where build pipelines\projects are configured and 
managed. 


After the plugin is installed, we need to configure information suchas the Qualys 
Container Security API gateway URL and the credentials to access the API endpoint 
within the plugin. The plugin regularly polls the the Qualys cloud platform using APIs 
for vulnerability information of scanned images. We also need to configure an image 
validation policy (gate policy) with the build pass/fail criteria, the data collection 
frequency and image details for validation. 


We then need to add the Qualys scan task to the build pipeline. This task must run 
after the image is built and before it is pushed to a registry. 
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Please consult the Qualys Container Scanning Connector guide for Jenkins, Bamboo 
or AzureDevOps for more information: 

https ://www.qualys.com/docs/qualys-container-scanning-connector-jenkins-plugin- 
user-guide. pdf 

https ://www.qualys.com/docs/qualys-container-s canning -connector-bamboo- plugin- 
guide.pdf 

https ://www.qualys.com/docs/qualys-container-scanning-connector-azure-devops- 
plugin-guide. pdf 
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Integrating Qualys Container Security into a CI/CD 
Environment (using script) 


Prerequisites 
jq (lightweight JSON processor) 
curl (command line tool to transfer data) 
Docker 
CICD Sensor 


Pipeline Configuration Steps 


Download the validate_image.sh script from GitHub 
Configure jq filter with image validation criteria 


Execute the script with correct arguments as a part of the build pipeline: 
-/validate_image.sh ${QUALYS_API_SERVER} ${USERNAME} ${PASSWORD} ${DOCKER_IMAGE_ID} 
OR 


-/validate_image.sh ${QUALYS_API_SERVER} ${USERNAME} ${PASSWORD} ${DOCKER_IMAGE_NAME} 


If you are using a homegrown CI/CD tool or a tool for which the Qualys plugin is not 
available, you can use scripts together with the CI/CD Sensor for securing build 
pipelines in suchas an environment. 


These scripts are available on GitHub 
https ://github.com/Qualys/community/tree/master/containerSecurity#validate- 


docker-image-without-plugin 


The scripts works as per the following workflow: 

e The validate_image.sh script tags the image with a predefined tag, so that the 
Qualys CI/CD Sensor scans it. (Sensor will untag it after scanning. If this is the only 
tag present on the image, it is not untagged to avoid image deletion.) 

e The script requires the Qualys API gateway URL and user credentials with API 
access. It periodically, polls the Qualys cloud platform for processed vulnerability 
data. 

e Once the processed vulnerability data is available, it applies the jq filter and 
evaluates the image. 

e The jq filter will cause an error if the image does not fit in criteria (configured as jq 
filter). Otherwise, no error is raised. 
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Secure the Build pipeline 
Functional Overview 


| 


| We 
CICD Sensor SS 

Scans Built CI Plugin Qualys Cloud 
Image @ Pulls Scan Platform 
Results (QCP) 


ceg KOO — & 
b locker 
Unprotected | Plugin 
Code CI Pipeline Image Batra 


CI Plugin 
Tags Image: 
qualys_scan_target:<image_id> 


This slide illustrates a CI/CD environment with the Qualys plugin and the Container 
Sensor. 


With the Qualys plugin and the Container sensor, you can secure the build pipeline 
and block images containing high risk vulnerabilities from entering your production 


environment. 


Now let’s understand how this works step by step: 


1. Developers write code and push it to some code repository (Eg. JFrog Artifactory). 


2. The Cl tool (Eg. Jenkins, Bamboo, etc.) executes a build job to package that code 


into a container image using one or more build nodes. 


3. The resulting image is tagged appropriately so that it can be identified as a scan 
target by the sensor. 
The CI/CD Sensor monitors Docker events on the build node. So as soon as the 


image is built, it scans the target image. 
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Next, the CI/CD Sensor passes on the scan data to the Qualys cloud platform for 


vulnerability association. 
The Qualys plug-in then pulls the scan results through APIs. 


The build fails if it does not meet the image validation criteria configured in the 


plugin. 


If the build passes the set criteria in the gate policy, it is pushed to an image 


repository (Eg. Docker) for deployment in a production or test environment. 
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Qualys Container Security in Azure DevOps 


Qualys Cloud Platform 


Qualys 


Container Qualys 
Scanning © CICD sensor(@) Docker Daemon 


Connector 


This slide illustrates an Azure DevOps based CI/CD environment with the Qualys 
Container Scanning Connector and the Container Sensor for scanning build pipelines 
managed by Azure DevOps. 


Azure DevOps is a Software as a service (SaaS) platform from Microsoft that provides 
an end-to-end DevOps toolchain for developing and deploying software. 

It comprises of Azure DevOps Services and the Azure DevOps agent. 

Developers use Azure DevOps Services to plan, work and collaborate in the cloud. 
The AzureDevOps agent has a predefined set of tools that are installed and 
configured for building and deploying your apps. 


The Qualys Container Scanning Connector for Azure DevOps should be deployed on 
the Azure DevOps Services. You can install the Connector from the Azure DevOps 
marketplace. 


The Qualys CI/CD Sensor should be installed where the docker daemon is running 
which is typically on the Azure DevOps agent. 


After installing the Container Scanning Connector, you can use this plugin as a task in 
the Azure DevOps pipeline. The plugin must include CS API access information and 
the image names(s) or image ID(s) to scan, data collection frequency, build failure 
conditions and other information. The plugintags the image with a predefined tag, so 


that the CI/CD Sensor on the DevOps agent can scan it. 


The Qualys scan task will either pass or fail the build job based on the vulnerability 


posture of the image(s) and generate a scan report for each container image in the 
build. 


Please consult the Qualys Container Scanning Connector guide for Azure DevOps 
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LAB 5 


Secure the Build Pipeline 


Please consult pages 28-32 in the Lab 
Tutorial Supplement for instructions to 


perform this lab activity. 


10 mins 


56 


In this section, we will provide a functional overview of the registry scanning process 
and discuss the steps involved in securing the container registry. 
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Addressing Container Lifecycle Concerns 


Container Registry 


b> e Registry scanning using Qualys 
Container sensor in Registry mode 


e Registry Hygieneto purgestale, 


Registry Scanning vulnerable images 


Registry Hygiene 
Vulnerabilities 
Image Source 


A successful Vulnerability Management program in a containerized environment must 
include scanning for vulnerable images in the container registry and practicing good 
registry hygiene. 


When we scanimages during the build phase, we have the metadata which identifies 
that the image was scanned at the build phase. So, when an image makes it to the 
registry, we can easily verify if it was scanned in the build pipeline. This information 
can then be used to ensure that unsecured and non-compliant images do not make it 
to production. 


Also, over time the set of images stored in registries can include out-of-date versions. 
They increase the likelihood of accidental deployment of a known-vulnerable version. 


So, registry scanning provides the necessary visibility that helps maintain proper 
registry hygiene and ensures that only compliant and secure images are retained in 
the registry. 
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Registry Scanning Steps 


Sensor Deployment, Adding Registry and Configuring Scan Jobs 


Identify Registries being Deploy Registry Sensor Add Registry 
used on host(s) that have information to your 
access to registry Qualys account and 
configure scan jobs 


To setup registry scanning, you need to first identify registries in use in your 
organization. Most organizations use more than one registry. They may have a central 
private Registry such as Artifactory or Nexus. And then there are ACR, GCR, etc. for 
cloud-based container deployments. 


The next step is to deploy the Registry Sensor. It’s recommended to setup a dedicated 
host for Registry scanning to avoid resource contention issues. 

The number of Registry sensors required will be based on your network topology, 
image inventory, the rate of change of images and scanning SLA’s. 


Requirements for Registry Scanning: 
1. Sensor must have access to all required registries. 
2. Sensor must have access to the Qualys platform. Communication through 
proxies is supported. 


Lastly, you need to add the required registry details to your Qualys subscription and 
configure scan jobs. Most registries including those that are cloud based, follow the 
Docker V2 API standard. The Registry Sensor runs a Docker V2 Catalog API call to list 
and scanimages ina registry. 
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Adding Registry 


@ Qualys. Enterpr 
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Q Search for registries... 
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Mea ea Public registries: Docker Hub, 
AWS ECR, GCR, ACR (Azure) 
Private registries: V2-private 
registry, Docker Private 
Registry, jfrog-artifactory 


User with read privilege 
for registry s canning 

User with read and write 
privilege, if using 
Container Runtime 
Security for instrumenting 
imagesinregistry 


Registry Connector is configured in the Container Security UI inthe Assets section, 
under the Registries tab. 


Using Qualys Container Security you canscan both public and private registries. 
Public registries are cloud-based registries hosted on Amazon, Azure and Google. And 
private registries are on-premise registries deployed on a private network suchas 
those hosted using jFrog Artifactory or Nexus. 


Qualys supports scanning only authenticated registries. Also, these registries must 
support the Docker V2 API standard. 


We recommend using an account that has read only access to the registry for 
vulnerability scanning. However, if you are alsoinstrumenting images with Qualys 
Container Runtime Security, you will need to use an account that has both read and 
write privilege to the registry. 
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Configuring scan Jobs 


€ Create New: Schedule 
Create Mede 


Scan Settings 


Create a on-demand 
job to baseline registry 
Filter images using 
creation date or image 
tags for scanning 


The final step in registry scanning is to configure registry scan jobs. 


You can perform an on-demand or a scheduled scan. Both type of scans can be 
configured in the Qualys cloud UI or using Qualys APIs. 


An on-demand or a manual scan is used to baseline the registry. 


Here you need to provide details of the target repository and images for scanning. 


You must provide the full repository path up till the last sub-directory containing the 
images you want to scan. 


Images can be filtered either using image tags or image creation date. Images are 
queued for scanning based on the filters defined in the schedule (e.g., scan images 
created in last 14 days or all images matching the “latest” tag) 
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Configuring scan Jobs 


€ Create New: Schedule 


Create an automatic 
scan job toscan all 
new images posted to 
the registry since the 
last scan 


Scan Settings 


An Automatic scanis a scheduled scan job. Here you need to provide details of the 
target repository and the time this job will run everyday. 


As this type of scanis anincremental scan, only new images that are added to the 
configured repository since the last scan, are considered for scanning. 


Registry Scanning 
Public Registry 


Docker V2 API call 


Vulnerability 


association Qualys Cloud Platform Images queued for 
and reporting scanning 


Listing Phase 


Scan image for Scanning Phase 
vulnerabilities Step 3 

Step 4 

Step 5 


Step 6 
Step 7 


This slide illustrates the steps in scanning an image repository hosted in a public 
registry such as AWS ECR, Azure ACR, Google GCR and Docker Hub with Qualys 
Container Security. 


Here registry scanning involves the following steps: 

1. The Qualys cloud platform makes the Docker Registry API calls and fetches 
information to pass on to the Registry Sensor(s) for performing an image scan. 

2. Images are queued for scanning based on the filters defined in the schedule by 
the user (e.g., scanimages created in last 14 days), 

3. Registry Sensors setup in your environment, poll the Qualys cloud platform 

periodically to see if any images are queued for scanning. Qualys assigns only a 

subset of discovered images to the sensor for scanning. The response payload 

includes image details along with the authentication credentials required to pull 

the image from the registry. 

The Registry Sensor then pulls these images from the target registry 

Next, the Sensor scans the image for vulnerabilities. 

Scan data is pushed to the Qualys cloud for processing. 

Qualys then runs signatures on the collected information and generates a 

vulnerability report which can be viewed on the Container Security application. 


So. oS 
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This slide illustrates the steps in scanning an image repository hosted in a private 
registry such as Nexus or jFrog Artifactory with Qualys Container Security. 


Here registry scanning involves the following steps: 

1. Registry Sensors periodically poll the Qualys cloud platform for scan job details. 
The response payload includes scan job details along with the authentication 
credentials required to pull the image from the registry. 

2. The Registry Sensor then makes Docker Registry API calls to the target registry 
and fetches information for performing an image scan. 

3. Next, the registry Sensor pulls the image(s) matching the filter criteria (based on 
matching tag(s) or date filter as defined in the scan job) from the target registry. 

4. The sensor then scans the image for vulnerabilities. 

Scan data is pushed to the Qualys cloud for processing. 

6. Qualys then runs signatures on the collected information and generates a 
vulnerability report which can be viewed on the Container Security application. 


i 
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Registry Scan Results 


© Qualys. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets TT MTC Registries 
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After the scan job completes, you can see a list of the total and scanned images from 
the registry along with the number of vulnerable images. 


Clicking the number under the vulnerable column will display the number of 
vulnerable images in the image repository. 
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LAB 6 


Secure the Registry 


Please consult pages 33-37 in the Lab 
Tutorial Supplement for instructions to 


perform this lab activity. 


10 mins 
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In this section, we will provide an overview of Qualys Container Runtime Security 
(CRS) and understand the steps to operationalize it. 
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Containers — Attack Scenarios 


Threat actors accessing containers 
— SSH, Shell or logginginto containers 
— Application vulnerability to spawn a shellinto a container 


Resource abuse 
— Malicious container instantiationsuch as Crypto Miners 


Changing files to gain access 

— Modifying access keys (ssh authorized_keys) 

— Updating /etc/passwd or /etc/shadowfiles to create users or escalate privileges 
Unused binaries and libraries can be used to compromise containers 


Using networking methods 
— Maliciously access external or internal resources 
— Serve new malicious applications to external or internal resources 


There are several possible ways to attacking a containerized deployment. This slide 
outlines some of the scenarios which might include: 
e External attackers attempting to access a deployment from outside 
e Internal attackers who have managed to access some part of the deployment 
e Attackers trying to hijack resources from the host by running a cryptocurrency 
miner 
e Malicious internal actors such as developers and administrators who have 
some level of privilege to access the deployment 
e Inadvertent internal actors who may accidentally cause problems 
e Application processes that, while not intending to compromise your system, 
might have programmatic access to the system such as through APIs 


Countering these type of attacks requires deep visibility into the container runtime 
environment and the ability to monitor and block malicious behaviour. 


Container Runtime Security (CRS) Overview 


Instrumented into the Docker image l 
and is a part of containerized 
applications = 


Serves as a “Function level firewall” for 
containers 


Granular security policies to control file, 
network and application behaviour 


Low footprint with little overhead on 
the container application 


D D? © D p con [po ee 
eo A Ceao A ee 


Deployable in any docker container m a 
environment based on-prem or cloud, Ke4 GPN Fa $ sos a 
whether owned or managed as ina 
Container-as-a-Service (CaaS) type of 
environment 


Amazon ECS 


Qualys Container Security includes Container Runtime Security (CRS) that provides 
deep runtime visibility and protection against runtime attacks. This is achieved by 
instrumenting images with Container Security components. We simply drop a few 
binaries into the image as the security layer. This process is known as 
instrumentation. Through this security layer we gather functional-level behavioural 
data from within a container which helps to visualise process activity. You can create 
and apply security policies that provide custom security controls based on the 
container’s activity. This solution addresses, in real time, container security use cases 
like critical file-access monitoring and blocking, network micro-segmentation, 
vulnerability and exploit mitigation, and virtual patching. 


The instrumentation is very lightweight and doesn’t impose much of a performance 
overhead on the container. 


CRS is implemented in the pre-deployment stage, either as a part of the build process 
or later when the image is pushed to the registry and scanned by the Registry Sensor. 


Container Runtime Security (CRS) can be deployed for both on-prem and cloud-based 
container deployments and is particularly useful for securing containers in a CaaS 
environment where the underlying host infrastructure is managed by a cloud service 
provider. 


Runtime Policies allow for custom security controls to be configured at file, network 
and application level, which serve as a “function level firewall” allowing, denying or 
monitoring activity, based on policy configuration. 


Note that Container Runtime Security is not enabled by default in your Qualys 
account. Please consult your Qualys TAM to enable Container Security Runtime for 
your Qualys Account. 
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In this topic, we will provide an overview of the steps, options and prerequisites for 
implementing and operationalizing Container Runtime Security in your environment. 
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Steps to Operationalize CRS 


Deploy the Instrumenter service or the CLI script on a Docker 
host 


Instrument images to add the runtime security layer to the 
image 


Assign a security policy to the image and choose a log mode 


Verify functionality within your environment 


This slide illustrates the steps involved in implementing Qualys Container Runtime 
Security. 


The workflow for Container Runtime Security starts with instrumentation of the 
target container image. Todo this you must deploy the Docker CLI script or the 
Instrumenter service in your environment. 


Next, you need to instrument images to add the Container Runtime Security layer to 
the image. 


You can then apply a security policy to the instrumented image to monitor and 
enforce certain behavioural restrictions on the container(s) spawned from that image. 
Qualys provides multiple out-of-box policies that can be readily used, or you create 
you own custom policies too. 


You can also choose a log mode to determine what information is logged for the 
container for policy hits (rule matches) and gather behaviour data. 


When you instantiate a container from the protected image, it inherits the policy 
applied to the underlying image. Based on the data gathered , you can visualize 
process activity within the container to understand its behavior. You can tune your 
policy to enforce the desired container behavior and verify functionality. 
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Instrumentation Requirements 


Qualys subscription with Container Security and Container Runtime 
Security enabled 


Docker host using a supported OS platform 


Access to the Qualys Cloud Platform (configure proxy option if host is 
running behind proxy) 


Vault with secret engine to pass credentials to the CLI script or 
Instrumenter service 


© Qualys 
Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Configurations Sensors Integrations Presence of “Runtime Policies” 


tab Indicates CRS is enabled for 
the account 


This slide outlines the requirements to deploy Qualys Container Runtime Security in 
your environment. 


Firstly, your Qualys subscription must have the Container Security module with the 
Container Runtime Security feature enabled. 

Please contact your Qualys Technical Account Manager for more details. If your 
account has CRS enabled, you will see the “Runtime Policies” tab under the 
Configurations section in the Container Security application user interface. 


Next, the OS platform of the Docker host where the Instrumenter service is installed 
must be supported. 


The Docker host that executes the script or has the Instrumenter service must be able 
to access the Qualys API gateway URL. Gateway is the base URL to the Qualys API 
server where your account is located. You can configure the proxy option for the 
Instrumenter service or the CLI script if your environment requires the use of a proxy. 


In secure mode, the Instrumenter service or the CLI script needs a vault with a secret 
engine to pass credentials to the service to authenticate to the Qualys API endpoint. 
You can set Qualys credentials using HashiCorp kv-v1 or kv-v2. Else the Qualys 
credentials are passed in plain text. 
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Instrumenting Images using CLI Script 


Functional Overview 
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This slide provides a functional overview of integrating Container Runtime Security in 
the Cl or build pipeline using the CLI script for instrumenting images. 


In this case, the workflow for Container Runtime Security starts with the scan of the 
image in the build phase of the container lifecycle. 


The build pipeline needs be configured to instrument images using the CLI script after 
it passes the image validation criteria defined within the plugin. This script must be 
available on the build node along with the CI/CD Sensor. 
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Instrument Image from the CS User Interface 


© Qualys. 


Container Security 


Assets 
Instrument Image 


REGISTRY and not source: INSTRUMENTATION Select the source registry from where to instrument the image, and then provide the destination registry 
to store the instrument image 
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Total images vepistry-1.dockerio 


Identify images scanned 
by Registry Sensor but e Reposi 
REGISTRY actions (1) e not yet instrumented qualyssa/demo 


VULNERABILITIES 


When using the Instrumenter service for instrumenting images, you can initiate the 
instrumentation job either from the CS use interface or using APIs. 


Note that in order to instrument an image this way, it must first be scanned by the 
Registry Sensor. You can identify such images, and which are not yet instrumented 
using the following search query: 

source: REGISTRY and not source: INSTRUMENTATION 


Also, the registry type must be supported. Currently, the Instrumenter service 
supports the following registry types: 

Public registries: Docker Hub 

Private registries: Docker v2 compliant private registry: Nexus, JFrog Artifactory 


Once you have identified the required image(s), you can choose the Instrument 
action from the Quick Actions menu. 


When an instrumentation request is submitted, the Qualys cloud platform federates 


the job request and assigns the task to any of the authenticated instrumenter service 


configured in your Qualys account. 
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Instrument Images using the Instrumenter Service 
Functional Overview 


Image pushed to registry 
after scanning in Cl phase 
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This slide provides a functional overview of the steps involved in instrumenting 
images using the Instrumenter service. 


1. Qualys usersubmits an instrumentation request in the Qualys Container Security 
application (or using APIs). 


2. The Instrumenter service on the instrumentation host regularly checks with the 
Qualys cloud platform for any instrumentation tasks. When an instrumentation 
request is initiated, it is assigned to an Instrumenter service setup in your 
environment. The Instrumenter then pulls the unprotected image from the target 
registry, inspects it, embeds the Qualys security layer and provides as output a 
new “instrumented” or protected version of the image. 


3. This new image is then uploaded back to the destination registry with “-layered” 
appended to the tag. 
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LAB 7 


Operationalize Container Runtime Security 


Please consult pages 38-44 in the Lab 
Tutorial Supplement for instructions to 


perform this lab activity. 


20 mins 
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In this topic, we will provide an overview of runtime security policy and policy rules 
and understand how these are applied to a container. 
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Runtime Policy 


Allows toenforcebehavior ofthe jaan 
container application Container Security 


Contains rules thatcanbeapplied [Mallia 


atthe application, file and the 
network level 


Can consist of multiple rules 


Can be setto Active, InActive or 
Permissive mode for tuning 
workflow 


Has defaultactions for each rule 
type (Allow, Deny, Monitor) 
e Default actionprocessedifno 


rule match for any ruletypein 
the policy 


You can apply a security policy to aninstrumented image to enforce certain 
behavioural restrictions to secure the container spawned from a protected image. 


Qualys provides out of the box policies for various scenarios so that you can get 
started with Container Runtime Security quickly. You can also create your own custom 
policies or update existing policies through the CS application user interface or using 
CRS APIs. 


Policies contain rules that can be applied at the application, file and the network 
layer. 


Policy Rules 


File Rule Network Rule Application Rule 
me mur Inbound\Outbound 
e Program IP lick 
e Path Port unction (syscall) 


* Action Protocol Argument 
Action Action 


Rules relate to system calls 
Act like a “function” level firewall 


Classified into three categories: 


- Application 
- File 


- Network © @ oO 
Rule Actions support = “ALLOW”, “DENY”, “MONITOR” 


At the heart of aruntime security policy is the individual policy rules that relate to 
system calls. System calls provide the services of the operating system to user 
programs via API. 


Rules act as a “function-level” firewall allowing you to whitelist or blacklist system 
calls. Forinstance, we can make the container talk to only a specific IP range or 
through a specific protocol or specific ports or a combination of all this 


We break policy rules down into three categories: 
- Application 

- File 

- Network 
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Network Rules 


Ay Network Rules (1) 
Define int 
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Network rules provide “standard” firewall capabilities 


A network rule at first glance can provide “standard” firewall capabilities — allowing or 
denying inbound or outbound IP connectivity between the container and a given IP 
address and port to block lateral or external communication. The network rule has 
these types: Network Outbound and Network Inbound. 


The first rule illustrated in the slide is a Network Inbound type of rule that is 
configured to block any IP Address to bind to the SSHD daemon on port 22. 


The second rule illustrated in this slide is a Network Outbound type of rule that is 
configured to block all outbound access from the container to port 5555 to stop 
unauthorized access through “LibMiner” which is a cryptocurrency mining malware. 
Please consult this Qualys blog post to know more this malware 
https://blog.qualys.com/product-tech/2020/01/17/libminer-container-based- 
cryptocurrency-miner-targeting-unprotected-redis-servers. 
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File Rules 


A [E] File Rules (3) 
Define read and write file a 


libminer_3adgbw_flag_d... 
libminer_symefget_init_d... 


libminer_symefget_bin_d... 


Default Action 


© Allow 


/tmp/.3adgbw_flag_una 


etc/init.d/symefget 


/usr/bin/symefget 


File rules control what files can be accessed or executed by the specified program 


File policy rules control what files a specified program can access or execute. 


The file rule illustrated in the slide blocks the execution of LibMiner malware. 


LibMiner downloads and executes the components from an attacker's server. It also 


drops the bash script 'symcfget' for persistence and registers it as a service. 
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Application Rules 
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Application rules allow you to specify the system call that should be filtered. 


Application rules are in a way a superset of the network and file rule types. With the 
other types, Container Security translates the rule to the appropriate system call(s). 
With application rules, one can directly specify the system call which should be 
filtered. 


Modifications to 'hosts' and 'resolv.conf' files can result in resolution of Domain name 
to malicious IP. The policy illustrated in the slide monitors all file Open’ events and 
denies or blocks all ‘Write’ type events on either of the specified files used for name 
resolution. 
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Apply Policy to Instrumented Image 
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Total Images 


Default Policy Default group policy 

Prevent using bash ~/.bash_profile and ~/.bashre are shell scripts. These shell scripts 

REGISTRY = tions (1) v Prevent shadow access This policy tracks the attempt to access the credential information. 

Account Discovery This policy tracks the attempt to discover the account information 

VULNERABILITIES 
verity 5 Prevent Local Job Sched... Cron jobs execution of prog 


Prevent CPU Resource Hi... Cryptocurrency miner communicates to mining pool using stratum 


Prevent SSH access Private Keys can be used for authenticating in Remote Services like 


The following query identifies images that have been instrumented: 
source: INSTRUMENTATION 


After filtering images by the source type, you can use the Quick Actions menu and 
select “Configure Policies” to apply a policy on the selected image. 


Only one policy can be applied to an instrumented image. 

You can change the policy applied to an instrumented image any time. A change in 
the policy assigned to the image will be applied to all the running containers spawned 
from the protected image. 


With CRS APIs, you can apply a policy to an image as well as to a container. 
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Configure Instrumentation- LogMode 


esr Configure Instrumentation 
Container Security ORTS © 
Assets Provide instrumentation code to gather trace informatior 
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Total images 


PolicyDeny 
None - - No events 
REGISTRY = Actions (1) © PolicyMonitor - - Only policy hit events with monitor action 
PolicyDeny - - Only policy hit events with deny action 
VULNERABILITIES š A 
a PolicyMonitorDeny - - Only policy hit events with monitor, deny actio: 
PolicyAllow - - Only policy hit events with allow action 


PolicyAll - - Only policy hit events with monitor, deny, allow actions 


Behavior - - Only detailed behavioral events 


All - - Includes PolicyAll & Behavior 


Once a policy is applied to an image, you can choose a log mode to determine what is 
loggedin a container for policy hits (rule matches) and runtime behaviour. This is 
analogous to putting a policy in debug mode to get varying levels of log data to be 
able to tune the policy. 


Click Configure Instrumentation in the Quick Actions menu of aninstrumented image 
to select the log mode. 


Container activities pertaining to files that are being read on the container, programs 
being run, IP address and ports accessed, policy hits, and action (allow, deny and 
monitor) details are logged as per the selected log mode. 


Additional log data for container behaviour monitoring can also be collected, if 
desired. Such logs show all syscalls made within the application container. 
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LAB 8 


Runtime Security Policy 


Please consult pages 45-48 in the Lab 
Tutorial Supplement for instructions to 


perform this lab activity. 


10 mins 
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In this topic, we will discuss the available options to monitor container runtime 
behaviour and verify container runtime protection. 
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Verify Runtime Protection 


Container Security app Container Host 
Ensure container 

“LogMode” is set to 
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Spawna container fromthe : y.qg3. apps -qua 
instrumented image : 


st-layered 


t docker exec -it eel03b2b02a2 


Connect to the container [fesse eID 
and performactions 


Analyze container “Event” Verify actionis allowed or 
data and “Runtime Profile” denied 


This slide outlines the steps to verify Container Runtime Security functionality in your 
environment. 


Ensure that you have set the correct log mode set on the image in the Container 
Security application, to monitor and analyse container activity and behaviour. 


To test runtime protection, spin up a container from the instrumented image : 
docker run -itd -e 
LIMQURL=https://gateway.qg3.apps.qualys.com/crs/vl.2 -e 
LI MQỌSKIPVERIFYTLS=true myregistry/centos:latest-layered 


And then perform actions within the container to validate your policy rules. 


Example scenario: 
Run the following commands to test a policy rule that blocks access to the 
/etc/shadow file when using the “cat” program: 
1. Exec into the container 
docker exec -it<containerid> /bin/bash 


2. List the contents of the /etc/shadow file 
cat /etc/shadow 
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Response example showing CRS blocked it: 
root@eel03b2b02a2:/ # cat /etc/shadow 
cat: /etc/shadow: Permission denied 


You can view information on policy hits, syscalls and activities performed within the 
container by monitoring container “Events” and the “Runtime Profile”, in the 
Container Security application. 
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View Instrumented Containers 


© Qualys 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets 
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Total Containers 


VULNERABILITIES 


Runtime Defense (Policy Hits) 


Under Assets > Containers you can perform a search for instrumented or protected 
containers using this search query: 
isInstrumented: true 


You can then View Details from the Quick Actions menu for any instrumented 
container to view the runtime telemetry information for the container. 


The Summary panel shows policy name and status along with Runtime Activity and 
Runtime Defense information for the container. 


Runtime Activity shows the number of syscalls made and Runtime Defense shows 
policy hits in the container inthe last 24 hours. 
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Container Events- Standard and Behavior Logs 


© Qualys. 
€ View Details: cfca38979d9c 


View Mode 


© Qualys 
€ View Details: cfca38979d9c 


View Mode 


socket:[55331] 


/var/log/httpd/access_lo 


The Events tab shows a log of when each resource being tracked is accessed, and 
whether the access was allowed, monitored or denied depending on the applied 
policy. 


You can use the filter option to view standard logs or behaviour logs. 


Standard logs show policy hits. 


Behaviour logs show system calls. The system call number is shown in the CALL 
column. 


Please consult the Qualys Container Runtime Security User Guide for more 
information on the supported syscalls. 
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Container Runtime Profile 


© Qualys 
<€ View Details: c4f9ecca4f26 


View Mode x 
Runtime Profile 


Last known information for this container 
Summary 


Container Details 


FILES READ PROGRAMS RUN PORTS ACCESSED IP ADDRESSES COMMUNICATED 
/dev/null 


Runtime Profile 


Installed Software 


Associations 


Vulnerabilities 


The Runtime Profile tab shows the resources that are tracked to gather trace 


information. It shows the files that are being read on the container, programs being 
run, ports accessed, and IP address information. 
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View All Container Events 


© Qualys 
Container Security HOME DASHBOARD ASSETS EVENTS REPORTS 
Events Event Details 


Q Search for event 


o Process /usr/sbin/httpd was allowed to access socket:{55331]. |— 


19.1K 


Total Events 


cfca38979d9c Behanor so) Summary 


ACTIONS tainer id p 
À cfca38979d9c cfca38979d9c /ust/sbin/httpd 


cfca38979d9c Behavior vi 3 
TYPES 
Boh 


socket:155331] 


*Event data is stored in the Qualys cloud platform for last 7 days of activity 


Runtime events pertaining all instrumented containers are listed under the Events 
section. 


You can use options on the left side bar to quickly find events by the action taken 
(Allowed, Denied) and the event type (Behavior, Standard). 


You can use the search field above the list to find events by event details like the 
container SHA the event is associated with, system call, process, and more. 


Here you can search events and then drill- down into event details. 


Note that currently all event data is stored for 7 days in the Qualys Cloud Platform. 
You can consider exporting event data using CRS APIs for long term retention. 
Please consult the Qualys Container Runtime Security API guide for more 
information. 


LAB 9 


Verify CRS Functionality 


Please consult 49 in the Lab Tutorial 
Supplement for instructions to perform this 


lab activity. 


10 mins 
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Summary 


> <+ 


YZ 
CICD Sensor | Registry Sensor FA CRS Protected ; 
Scans Built CI Plugin Scans Registry a Cloud Containers panes) 
Image Pulls Scan atform Push Alerts to QCP 
© © (QCP) 


Results 4 


</> — — — Q — © —> D — — ”> — 
ip , docker El Deploy © @ 


Unprotected CI Plugin cicak Instrumented 


Code CIPipeline Image cD 
P 8 Build Pass Pipeline Image Run Protected Scan Running 
P Containers Containers 


CI Plugin 
Tags Image: 
qualys_scan_target:<image_id> 


Genera 


Sensor 


Qualys Container Security integrates with the build-ship-run phase of the container 
lifecycle, addressing each one of those challenges we discussed initially, which if not 
addressed, can make container technology adoption a challenging proposition. The 
CS application seamlessly integrates with different CICD tools supporting automation 


and providing security through self-service to DevOps teams, supports scanning of 


different types of registries and helps you maintain registry hygiene, identifies 
container drift and provides deep visibility and protection in your runtime 
environment. 
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Last Reminders 


Certification Exam 

30 multiple choice questions. 

Answer 75% of the questions correctly to receive a passing score. 
Candidates will receive 5 attempts to pass the exam. 


You may use the Container Security Assessment Response presentation slides and lab tutorial 
supplement to help you answer the exam questions. 


Trial Account 
httos:/AWwww.qualys .com/free-trial/ 


Training Survey 
https ://forms.office.com/r/rs YOAja6Xz 


See the bottom of Swapcard session for the 3 links mentioned above. 


The link to enrol for the course and the certification exam is 
https ://gm1.geolearning.com/geonext/qualys/scheduledclassdetails4enroll.geo?&id= 
22511237814 


Please consult the Lab Tutorial Supplement for information regarding registration for 
the Container Security Assessment and Response course certification exam. 

NOTE: We recommend that you take this certification exam at the earliest possible 
convenience. 


You can request a free Qualys limited trial account by submitting a request on this link 


httos:/AWwww.qualys .com/free-trial/ 
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Qualys. 


